REMARKS 

The office action and references cited therein have been carefully 
considered together with the present application and only minor amendments have been 
made to a few claims. Claim 5 has been amended to more accurately define the system 
and to emphasize pre-existing differences between the system as claimed and the prior art 
that has been cited and applied by the examiner. Claims 7, 12 and 57 have been amended 
to correct grammatical errors. 

The examiner has rejected claims 1-6, 10-27 and 33-69 as being anticipated 
by Kardos et al. U.S. Patent No. 6,430,562 (hereinafter referred to as "Kardos") and has 
rejected the remaining claims under 35 U.S.C. § 103 over Kardos in view of Hull et al., 
U.S. Patent No. 6,487,457 (hereinafter referred to as "Hull"). 

As will be extensively discussed herein, applicants believe that Kardos 
simply does not anticipate, teach or suggest the claims of this application as amended, 
applied singularly or in combination with Hull. With regard to the anticipation rejection, 
the Court of Appeals for the Federal Circuit has enunciated the law of anticipation clearly 
and unambiguously in its decisions for many years. It is difficult to anticipate claims 
because a very high standard is required. An invention is anticipated if the same device 
or method, including all the claim limitations, is shown in a single prior art reference. 
Every element of the claimed invention must be literally present in the prior art. Scripps 
Clinic and Research Found, v. Genentech, Inc., 927 F.2d 1565, 1576 (Fed. Cir. 1991); 
Richardson v. Suzuki Motor Co., 868 F.2d 1226, 1236 (Fed. Cir. 1989); Connell v. Sears, 
Roebuck & Co._, 122 F.2d 1542, 1548 (Fed. Cir. 1983). The identical invention must be 
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shown by the prior art reference in as much detail as is contained in the patent claim. 
Richardson v. Suzuki Motor Co., Ltd., 868 F.2d 1226, 1236 (Fed. Cir. 1989 j; Continental 
Can Co. v. Monsanto Co., 948 F.2d 1264, 1267 (Fed. Cir. 1991); Titanium Metals Corp. 
v. Banner, 778 F.2d 775, 780 (Fed. Cir. 1985). 

The examiner has exaggerated and distorted the teachings of Kardos in the 
rejections of the claims of this application. Kardos is not directed to a system for 
managing operational facilities, but in fact is stated to be an improvement of a mobile 
work force management system where a utility can dispatch and schedule work orders 
such as meter and service orders, with the improvement permitting communication with 
multiple hosts rather than a single host system. The stated advantages of Kardos is that a 
mobile work force system may be "integrated across an enterprise". This allows multiple 
types of work, such as customer initiated work, planned maintenance, door postings, one- 
call work orders and the like to be assigned and tracked using a single system. 

Apart fr^m-monitoring the progress of completion of work orders, Ka rdos has no 
inspectiqt& ^abi lity) nor is there any selective auth orization or operability that is a 
function of the log-in identity of clients. While the system claimed in the present 
application has work order functionality, that work order functionality comprises only a 
small part of the capabilities of the system of the present invention. Moreover, many of 
the claims of the present invention describe functionality that is not even remotely 
anticipated, taught or suggested by Kardos. 

This is true with respect to claim 1 which claims a system for managing 
operational facilities which is of the type which utilizes predefined events to carry out 
managing operations for the facilities, and which comprises, inter alia, "at least one client 
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having a unique log-in identity adapted to selectively send events to said server via said 
communication link, and a clearing house . . . adapted to selective authorize 
predetermined events by each client according to said log-in identity of each such client 



. . ." There is nothing in the Kardos patent that even remotely shows or suggests a 
clearing house^ttiansadapted to selectively authorize predetermined events by each client 
according to said log-in identity of each such client. The Kardos system appears to have 
unrestricted communication and does not utilize a log-in identity of each client to limit 
authorization of what can be done by anyone in the work force. The examiner's 
reference to column 4, lines 30-65 in Kardos as meeting the clearinghouse element of 
claim 1 is clearly misplaced. There is no discussion whatsoever concerning authorization 
of predetermined events by each client according to said log-in identity of each such 
client. This claim should be allowed. 

Claim 4 further defines the system wherein one or more of said server, clearing 
house and client includes means for defining various levels of authorization for limiting 
access to predetermined events. Clearly, not only does Kardos not have the log-in 
identity as defined in claim 1, but totally fails to anticipate, teach or suggest having 
various levels of authorization as is set forth in this claim. 

Claim 5 further defines the system wherein one or more of said server clearing 
house and client include predefined templates for selected events wherein said templates 
comprise a plurality of checklist items and possible responses to said checklist items. 
Nowhere in Kardos is there even a hint of the use of predefined templates for selected 
events wherein the templates comprise a plurality of checklist items and possible 
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responses to those checklist items. Kardos simply is not designed to have this capability 
and therefore cannot anticipate, teach or suggest this claim. 

Claim 6 further defines applicants' system wherein said predefined events include 
one or more events selected from the group consisting of 19 separate events which relate 
to notification events, tasks events, set up events, work requests and request processing 
events, as well as work order and work order processing events. Assuming for the sake 
of argument that Kardos teaches or suggests any of these events, it cannot be honestly 
concluded that only a few of the events are comparable to those 19 events that are set 
forth in claim 6. Kardos is not designed to operate in the manner described in this claim 
and certainly cannot anticipate, teach or suggest a system having this functional 
capability. 

With regard to claim 7, it further defines a system as creating a notification event 
responsive to preselected ones of said predetermined events not having been completed 
as prescribed and are therefore overdue. The examiner admits that Kardos is silent 
regarding the functionality of this claim and cites Hull as supplying the deficiency in an 
obviousness rejection. However, Hull fails to teach or suggest the subject matter of this 
claim because there is no notification event produced by Hull responsive to the event 
being overdue. The citation to column 12, line 65 to columns 13, line 10 which the 
examiner apparently relies on is totally misplaced. Hull merely contacts a designated 
person if the system cannot find utility rates in the context of a building management 
system. Additionally, Hull does not create a notification event responsive to preselected 
ones of said predetermined events not having been completed. 
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With respect to claim 11, it claims a system wherein during preselected ones of 
said events an authorized client is adapted to add new data, edit existing data or exit said 
event. Kardos fails to anticipate, teach or suggest this claim because it simply does not 
operate in the manner whereby an authorized client can add new data, edit existing data 
or exit the event. Claim 12 should be allowable for similar reasons. 

With respect to claim 13, it further defines the system wherein said clearinghouse 
selectively provides authorization to said client to request events in response to said client 
communicating its unique log-in identity to the server. Since the Kardos system is not 
concerned with authorization or unique log-in identities, it is incapable of anticipating, 
teaching or suggesting the subject matter of this claim. 

Claim 14 is similarly incapable of being anticipated, taught or suggested by 
Kardos for the reason that it does not have a download tasks event that can be requested 
after authorized communication is established. Moreover, claim 15 further defines 
additional functionality when during said download tasks event the authorized client 
downloads task list data from the clearinghouse and determines whether the data is valid 
and also determines whether communication with said server is disconnected when the 
task list data is not valid. Kardos simply is incapable of anticipating, teaching or 
suggesting the subject matter of this claim because Kardos simply does not operate in this 
manner. 

Claim 16 adds further functionality wherein during one of a download tasks event 
or an upload task event, said authorized client is adapted to make an entry into in an 
exception log when communication with said one server is disconnected. Kardos does 
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not operate in this manner and the notion of an exception log is not mentioned anywhere 
in the Kardos patent. 

Claim 17 further defines the system of claim 16 wherein during one of said 
downloads tasks event or said upload task event, said authorized client is adapted to 
check communication for a predetermined maximum retry count when communication 
with the server is disconnected and make an entry an exception log once the 
predetermined maximum retry count has been tried. Kardos does not operate in this 
manner and is therefore incapable of anticipating, teaching or suggesting the subject 
matter of this claim. Claims 18 and 19 define additional functionality during the 
download tasks event that is incapable of being performed by Kardos and is not 
anticipated, taught or suggested by Kardos. 

Claim 23 further defines the system wherein during said performed task event said 
clearinghouse is adapted to forward checklist item data for said task to said server. Claim 
24 further defines the system wherein during said performed task event said server is 
adapted to send said checklist item data to said authorized client and claim 25 further 
defines a system wherein during said performed task event, said authorized client is 
adapted to display a list of the checklist items from the checklist item data for completing 
said checklist items. Kardos simply does not operate in this manner because it does not 
utilize checklists in the manner as claimed. Further, claim 26 defines a system wherein 
during said performed task event, said authorized client is adapted to respond, skip or 
stop said checklist item from said checklist item data until all checklist items have been 
completed. This claim is not anticipated, taught or suggested by Kardos because it does 
not operate in a manner which utilizes checklists and certainly does not facilitate the 
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functionality whereby the authorized client can respond, skip or stop each checklist item 
from the data as claimed. 

Claim 27 further defines the system wherein during said performed task event, 
said authorized client is adapted to exit the display as claimed, store response data for 
said checklist item when the client elects to respond to the same and respond, skip or stop 
the next item from the checklist item data when said authorized client elects to skip said 
first checklist item. Clearly Kardos does not utilize checklist items in the manner as set 
forth in this claim and therefore cannot anticipate, teach or suggest it. 

With regard to claim 28, it defines the system wherein during said job site set-up 
event, said authorized client can execute a contact set-up event, a vendor set-up event, an 
inspection set-up event and a special action set-up event. While the examiner has 
rejected this claim as being obvious over Kardos in view of Hull, it is submitted that 
Kardos certainly does not operate in a manner which teaches or suggests these specific 
events because it does not contemplate or use a vendor set-up event and it does not 
perform inspections so that an inspection set-up event is not ever carried out. Hull is 
stated to disclose a system that includes these events with the examiner citing column 12, 
line 59 to column 13, line 9. However, when that text is reviewed, it is readily apparent 
that there is nothing written or alluded to, suggested or implied that relates to inspection 
data or a vendor set-up. Hull has nothing to do with inspections and in fact relates to 
what happens when a client cannot obtain utility rates in a building supervision and 
control system. In case there is a failure to obtain rates, contact information is used to 
attempt to contact designated personnel of the inability to obtain utility rates. This has 
nothing to do with vendor set-up or inspection data as claimed. 
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Claim 29 also further defines the system wherein an inspection set-up event 
further includes a checklist item set-up event that allows an authorized client to input and 
edit checklist item data for said jobsite data. Clearly, neither Kardos nor Hull has this 
stated capability. 

Claim 30 further defines a system wherein performance rating type set-up event 
allows said authorized server to display an option menu for yes/no type, multiple options 
type and numerical type performance rating to said authorized client for selection. There 
is no inspection carried out by either Kardos or Hull and therefore this claim cannot be 
taught or suggested by either Hull or Kardos. Moreover, since they do not do inspections 
and are not concerned with performance rating, they clearly do not have the capability of 
displaying an option menu for the various types of performance rating that are set forth in 
this claim. 

Since they do not perform the performance rating type set-up event, neither of 
these references can teach or suggest the subject matter of claim 31 which saves the 
performance rating type data onto said database. Further, claim 32 cannot be taught or 
suggested by Hull or Kardos for the reason that they simply do not define tolerance levels 
to create a special action event for performance rating data stored in the database. Kardos 
and Hull cannot teach or suggest this claim because neither is designed to carry out 
inspections at all, much less carrying out a performance rating or define a tolerance level 
to create a special action event based on performance rating type data. 

Claim 33 is not taught or suggested for the simple reason that neither 
Kardos nor Hull teach or suggest inspection functionality and particularly the 
functionality of an authorized client inputting and editing inspection templates data for a 
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specific jobsite. They simply do not have this functionality. Similarly, claim 34 cannot 
be taught or suggested by Kardos or Hull because they are not concerned with inspection 
templates data, much less inspection steps that are carried out according to a default 
checklist item data or a user defined checklist item data stored in said database. The 
words "inspect" or "inspection" do not appear anywhere in either the Kardos or Hull 
patents. 

Claim 35 further defines the system wherein said clearinghouse is adapted to 
respond to inspection data sent from an authorized client during an inspection processing 
event and determine whether the inspection data from said authorized client are valid. 
Not only are Kardos and Hull not concerned with inspection capability, neither patent 
discusses determining whether received inspection data is valid. The only checking that 
appears to be done by Kardos is to determine whether messages were received, which is 
completely different from what is claimed. 

Claim 36 further defines the system wherein during said inspection processing 
event the clearinghouse is adapted to make an entry in an exception log when said 
inspection data is not valid and is not taught or suggested by Hull or Kardos, applied 
singularly or in combination for the same reasons set forth with regard to claim 35. 
Claims 37, 38 and 39 are not taught or suggested by Kardos or Hull, applied singularly or 
in combination for the same reasons that were set forth with regard to claims 30, 31 and 
32 relating to tolerance levels. 

With regard to claim 41, it further defines the system wherein during said work 
request event, said clearinghouse is adapted to create a notification event for said at least 
one server to send said revised existing work request data to a contact person for approval 



32 



when said list of available jobsites to said authorized client is empty. This as well as 
claim 42 which is similar but describes the authorized client sending a message to a 
contact person is not taught or suggested by Kardos or Hull, applied singularly or in 
combination. Kardos simply does not handle work request events in the manner as 
claimed nor is the claimed creation of a notification event for sending said revised 
existing work request data to a contact person carried out as a function of the list of 
available jobsites to said authorized client is empty. 

Claim 46 further defines the system wherein during said work request processing 
event, said authorized client is adapted to enter an approval code when said authorized 
client accepts a selected open work request from said list. The notion of a client entering 
an approval code when said authorized client accepts a selected open work request is 
simply not a capability that is discussed, inferred or suggested by Kardos. Approval in 
this context or any context is not even mentioned in the Kardos patent. For similar 
reasons, claims 47 and 48 are not anticipated, taught or suggested by Kardos. 

With regard to claim 49, it defines a system wherein during said work request 
processing event, said authorized client is adapted to enter an explanation for said 
selected work request data when said authorized client rejects a selected open work 
request data stored in said database. Kardos does not teach or suggest the functionality of 
the authorized client rejecting a selected open work request data. Any rejection of a work 
request in Kardos is done at the server level, i.e., there aren't enough resources in the 
workforce to carry out some requested work. This is a very different functionality. The 
notion of a client rejecting a work request is simply not contemplated or discussed in 
Kardos. 
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Claim 68 is directed to a method for managing operational facilities using 
predefined events to carry out managing operations for the facilities as claimed and 
includes the step of selectively authorizing, by the clearinghouse, said events from each 
client according to said log-in identity of each such client among the other steps as set 
forth in the claim. Because Kardos does not selectively authorize events according to the 
log-in identity of each client, it certainly fails to anticipate, teach or suggest this claim. 
The arguments that are set forth with regard to claim 1 above also apply here. Claim 70 
is also believed to be allowable for the same reasons that were advanced with regard to 
claim 1. 

With regard to the dependent claims that were not specifically discussed herein, 
these claims depend from one or more other claims and necessarily include the subject 
matter of those one or more claims in addition to reciting further structure and/or 
functionality not found in those claims. Because of these reasons, it is also believed that 
these dependent claims are allowable. 

The new claims presented herein merely claim features and functionality that are 
set forth in the specification particularly the two full paragraphs that begin on page 7 
relating to global positioning technology. 
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For these reasons, applicants respectfully request reconsideration and allowance 
of all claims presenting appearing in the application. 

Respectfully submitted, 
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